The amount and variety of data that computer users store in digital form is ever increasing. As a result, users are increasingly interested in controlling access to their data. One way to control access is to manually encrypt sensitive files, for example by using any of a multitude of commercially available file encryption products. Only those with the decryption key may then decrypt, view, and modify the data. However, encrypting and decrypting files manually each time access is desired is tedious.
Another way to control access to data is through a secure logon process. Certain files can be associated with a user profile on a computer, and that profile can be accessible only to those that know the profile password. Users of the popular MICROSOFT WINDOWS® operating system are familiar with a process whereby a user profile is selected and a password is entered as part of booting a computer. This solution works well for most purposes, however certain security loopholes remain.
First, an attacker bent on accessing sensitive profile data may discover a way to circumvent the logon process. Second, stray data that is left on a machine when the machine is transferred may be inadvertently left in the clear on a machine. For example, some data may not be encrypted as part of a user's profile, but may be instead stored in an easily accessible location for anyone using the machine to stumble upon. A machine transfer may occur by reason of theft, such as the theft of a laptop, but may also occur in a number of other circumstances such as the sale or trade of a computer. Thus, there are multiple ways that sensitive data may be exposed, but no multipronged solution for these security issues.
To address, first, the compromise of sensitive data via a targeted attack, an operating system may be designed to provide some level of trustworthiness as to its behavior. However, the time before an operating system has loaded is particularly vulnerable to attack, since the infrastructure that protects the operating system from attacks may not have been established yet (or may be in the process of being established). Thus, ensuring that an operating system loads in a predictable way is important for protecting the operating system, and a user's sensitive data, from certain classes of attacks.
One type of security breach that can flow from non-secure loading of an operating system relates to the protection of the key (or keys) that enable certain restricted functionality. By way of example but not limitation, the MICROSOFT WINDOWS® operating systems employ a system key, or “SYSKEY,” that is used to protect various processes by making the correct performance of those processes dependent on the availability of SYSKEY. For example, the key needed to decrypt private information that is stored by the operating system in encrypted form may be derivable from the SYSKEY.
Conventionally, the keys needed to perform restricted operations are protected by the logon procedure. Typically, the user must correctly authenticate himself (e.g., by providing correct logon credentials, such as a username/password combination) prior to commencing use of the system. Use of the keys is enabled only if the user correctly authenticates, and the system will only permit the user a limited number of tries (e.g., three) before concluding that the user has failed to logon properly. (This type of limit on the number of attempts to logon prevents unauthorized users from enabling use of protected functionality by using a brute force attack to guess the password in the case of, say, a stolen laptop computer.) However, using the logon procedure to protect access to keys assumes that the operating system loader correctly loaded the operating system with the correct logon program, and that the use of the keys has not been otherwise enabled by rogue code that may be running. If a rogue loader was used instead, and the rogue loader causes a rogue logon program to be loaded with the operating system, then the use of keys might be enabled, or the keys might even be divulged, without the correct credentials having been entered. Since the loading of the operating system provides an opportunity for a security breach, protection of the keys in such a situation requires that the loading of the operating system take place under circumstances where it can be verified to take place correctly. Thus, a secure boot process can be used in combination with the protections afforded by a loaded operating system to provide a first layer of protection for the data on a computer. To this end, a secure boot process for a computer enabled with a trusted platform module (TPM) has been developed by MICROSOFT®, as can be understood with reference to U.S. patent application Ser. No. 11/031,161, filed Jan. 7, 2005, entitled “Systems and Methods for Securely Booting a Computer With a Trusted Processing Module.” Also related to this application are U.S. patent application Ser. No. 11/035,715, filed Jan. 14, 2005, entitled “Systems and Methods for Boot Recovery in a Secure Boot Process on a Computer with a Hardware Security Module,” and U.S. patent application Ser. No. 11/036,018, filed Jan. 14, 2005, entitled “Systems and Methods for Updating a Secure Boot Process on a Computer with a Hardware Security Module.” and U.S. patent application Ser. No. 11/036,018, filed Jan. 14, 2005, entitled “Systems and Methods for Updating a Secure Boot Process on a Computer with a Hardware Security Module.”
Most TPMs today conform to the TRUSTED COMPUTING GROUP® (TCG) standard, presently available at https://www.trustedcomputinggroup .org/home and entitled “Trusted Platform Module (TPM) Specification Version 1.2.” The TPM is a subsystem that may be incorporated into computing platforms to establish trust for the code that is executed by a platform. Standardization of mechanisms for establishing trustworthy code is beneficial because it allows the security and cryptographic community to assess the mechanisms for providing security, and because it promotes customer understanding and trust of new software features. It also encourages innovation in implementing and improving the standard, as contemplated and encouraged by the TCG®. As stated in the TCG® specification, “[m]anufacturers will compete in the marketplace by installing subsystems with varying capabilities and cost points.” While the invention provided herein is not limited to platforms implementing the TCG standard, it is operable with such systems and leverages concepts and technologies that can be understood with reference to the TCG® standard.
Even when a secure boot process is used, certain vulnerabilities remain. There is potential for human error in the storage location of protected data and observation of security protocols, which an additional layer of protection may help to abate. For example, users of machines with a secure boot option may not turn the secure boot feature on. This results in a security risk, especially for large businesses with multiple computers that may be transferred many times between people with differing levels of authority to access such data.